In packet switched networks such as the Internet, there is presently no efficient way to maintain session persistence when a session transforms from an unsecured session (e.g., HTTP) to a secure session (e.g., HTTPS). In architectures using megaproxies (e.g., redirecting users to cached versions of web sites, or for control, surveillance and data mining purpose, as is sometimes done by ISPs and enterprises), the use of cookie switching or URL switching in a load balancer (LB) are sometimes used.
In web applications, a LB may use a URL or cookie in a HTTP request to select an appropriate server. However, in order to examine the application packets, the LB must postpone the binding of a TCP connection to a server until after the application request is received. This is an example of “delayed binding”. In a delayed binding scenario, the LB completes the TCP connection setup with the client on behalf of the server. Once the HTTP request is received, the LB selects the server, establishes a connection with the server, and forwards the HTTP request. The LB must translate the sequence number of all reply packets from the server to match what the LB used on the client-side connection. The LB must also change the ACK sequence number for packets from client to the server. Delayed binding therefore impacts the performance of the LB because of the need for sequence number translation, and delayed binding can also increase the response time of a user's request to an application running on a server.
In shopping-cart applications, the LB typically must associate the first HTTPS connection request from a client with an earlier HTTP request received from the client. Source IP-based persistence does not work well when dealing with a mega proxy server, because when a user transitions from HTTP to HTTPS, the LB can no longer read the cookie because the cookie is encrypted.
Current practices for HTTP to HTTPS transition include the use of a shared back-end storage or database system. When the SSL (or TLS) session is initiated, the SSL server obtains the shopping-cart information from the back-end database and then processes it. However, this solution requires the server with the shopping cart to write the information to a back-end database. Another known option is to use middleware software to make all the servers appear as one big virtual server to the client application. A cookie is used to track the user identification. Once the application receives the first HTTPS request, the application uses the cookie to retrieve the data structure that contains the correct context.
In another known solution, a LB may be configured to bind a different port number on the virtual IP address (VIP) to port 443 of a different real server. When the real server generates the Web page reply that contains the checkout button, the LB links its own port number to that button (e.g., by generating a hyperlink for the checkout button).
In another known solution using an SSL accelerator, the SSL acceleration product terminates secure connections and converts the HTTPS request to an HTTP request. The LB redirects requests received on port 443 to the SSL accelerator, and maintains session persistence via a cookie or other method that is no longer encrypted.
Each of these known solutions consumes resources and overhead within a LB, thereby reducing the number of sessions and/or the amount of traffic the LB could otherwise handle.